Part 0. 개요 — 신뢰경계와 C가 위험한 이유

왜 지금 이 교육을 하는가 — 제도적 배경과 C 언어가 특별히 위험한 이유, 그리고 58개 항목 전체를 관통할 학습 렌즈를 먼저 정리한다. 출처: 「전자정부 SW 개발·운영자를 위한 C 시큐어코딩 가이드」(3판, 2012.9, 행정안전부·KISA)

소프트웨어 개발보안이란

광의: SW 개발생명주기(SDLC) 전 단계(요구사항·설계·구현·시험·운영)에 요구되는 보안활동 전체. 협의(오늘 다루는 범위): 구현 단계의 시큐어코딩 — C 소스코드에서 58개 보안약점을 식별하고 제거하는 방법.

용어	뜻
보안약점(Weakness)	공격을 유발할 “가능성”이 있는 잠재적 결함
보안취약점(Vulnerability)	실제로 공격에 이용될 수 있는 상태

시큐어코딩은 “취약점이 터진 뒤 패치”가 아니라 “약점 단계에서 미리 제거” 하는 활동이다.

시점	내용
2009	전자정부서비스 SW 보안약점 진단·제거 연구 착수
2011	C 시큐어코딩 가이드 제정(1판)
2012.6	「정보시스템 구축·운영 지침」 개정 — 전자정부서비스 개발 시 적용 의무화
2012.9	보안약점 항목·내용 변경(3판, 본 시리즈의 기준)

적용 범위: 신규로 개발되는 소스코드 + 유지보수로 변경되는 소스코드. 기존 코드를 전부 뜯어고치는 것이 아니라 “지금부터 손대는 코드”에 적용하는 것이 원칙이다.

다른 언어가 런타임에서 대신 막아주는 것을, C에서는 개발자가 손으로 막아야 한다.

경계 검사가 없다 — 배열·포인터로 버퍼 밖을 읽고 써도 언어가 막아주지 않는다. 오류가 나는 게 아니라 “옆에 있는 메모리”가 조용히 바뀐다. → Part 1 메모리 경계 계열
정수 연산이 조용히 넘친다 — 오버플로우가 예외가 아니라 랩어라운드다. signed 오버플로우는 표준상 정의되지 않은 동작이라 컴파일러가 검사 코드를 지우기도 한다. → Part 1 정수·타입변환 계열
자원을 손으로 관리한다 — malloc/free, open/close 의 짝을 개발자가 모든 실행 경로에서 직접 맞춰야 한다. 에러 경로에서 가장 자주 빠진다. → Part 5 코드 오류
표준 라이브러리에 지뢰가 있다 — gets, strcpy, sprintf 처럼 애초에 안전하게 쓸 수 없는 함수가 표준에 포함되어 있다. 호출하는 것 자체가 결함이 된다. → Part 7 API 오용

58개 항목을 관통하는 하나의 질문:

“이 데이터는 어디에서 왔고, 나는 그것을 왜 믿고 있는가?”

보안약점은 대부분 왼쪽 칸의 값이 검증 없이 오른쪽 칸의 자리(질의문·경로·크기·인덱스·권한 판단)로 넘어갈 때 생긴다. 이후 모든 Part의 항목에서 이 이동을 먼저 찾는 것이 체화의 핵심이다.